Alex Crichton [Wed, 25 Apr 2018 17:41:33 +0000 (10:41 -0700)]
Fix renaming crates as they come from 2 sources
Previously there was a verification in manifest parsing that the same dependency
must come from the same source, but this erroneously triggered an error to get
emitted when the `package` key was used to rename crates. The first change here
was to update that clause to key off the `rename` field rather than the `name`
field.
Afterwards, though, this exposed an existing bug in the implementation. During
compilation we have a `Resolve` which is a graph of crates, but we don't know
*why* each edge in the dependency graph exists. In other words we don't know,
when looking at an edge of the graph, what `Dependency` caused that edge to be
drawn. We need to know this when passing `--extern` flags because the
`Dependency` is what lists what's being renamed.
This commit then primarily refactors `Resolve::deps` from an iterator of package
ids to an iterator of a tuples. The first element is the package id from before
and the second element is a list of `Dependency` directives which caused the
edge to ber driven.
This refactoring cleaned up a few places in the backend where we had to work
around the lack of this knowledge. Namely this also fixes the extra test added
here.
Auto merge of #5394 - henriklaxhuber:master, r=alexcrichton
Pass linker path to build script
This change adds the environment variable LINKER to pass the path of the linker used by cargo to the build script. This complements the variable RUSTC (the rustc binary used) to give the build script full knowledge of its environment.
A specific usage example would be automatically generating bindings to system headers in cross compilation, e.g. by locating jni.h for android targets.
Adds a target directory parameter, that acts in the same manner as the environment variable `CARGO_TARGET_DIR`, to the following subcommands:
- `bench`
- `build`
- `check`
- `clean`
- `doc`
- `package`
- `publish`
- `run`
- `rustc`
- `rustdoc`
- `test`
Auto merge of #5398 - dwijnand:drop-legacy-paths, r=matklad
Drop legacy path support under Rust edition 2018 (or later)
builds on #5335
submitted for early feedback: wdyt @matklad? is this what you had in mind? what should change? what should be added? how should we test this? is the current (2015) messaging enough to drop it in 2018?
Henrik Laxhuber [Mon, 23 Apr 2018 15:11:10 +0000 (17:11 +0200)]
Added tests for RUSTC_LINKER buils script env var
Added tests for the environment variable RUSTC_LINKER that is
passed to the build script.
Also slightly improved readability of the code responsible for
passing the env var.
Henrik Laxhuber [Fri, 20 Apr 2018 15:04:14 +0000 (17:04 +0200)]
Pass linker path to build script
This change adds the environment variable LINKER to pass the path
of the linker used by cargo to the build script. This ammends the
variable RUSTC (the rustc binary used) to give the build script
full knowledge of its environment.
A specific usage example would be automatically generating bindings
to system headers in cross compilation, e.g. by locating jni.h for
android targets.
Auto merge of #5391 - varkor:check-message, r=alexcrichton
Print "Checking" for cargo check
I often alternate between `check` and `build` and I'd like to be able to tell which is currently happening (short-term memory being what it is, and "compiling" implying to me that codegen is occurring). Changing the message to "Checking" seemed to be reasonable (and there was precedent for `doc` with "Documenting").
Auto merge of #5390 - matklad:new-feature-behavior, r=alexcrichton
Enable new behavior of `--feature`
So far, the feedback on https://internals.rust-lang.org/t/help-us-test-the-breaking-bug-fix-to-cargo-features/7317 has been positive, so here's a PR to try this in nightly.
Note that the logic is slightly tweak for the case `cargo build -p not-a-workspace-member`: we want not only to resolve all ws members in this case, but to enable all of their features as well!
As a sanity check, this seems to be forward compatible with further improvements to features:
1) when we solve the grand bug of features being unified across the whole workspace, `cargo build -p not-a-member` would hopefully just work without additional contortions.
2) we might add a way to specify features per package, like `cargo build -p foo -p bar --features "foo/serde bar/serde"`
Auto merge of #5392 - ehuss:test-does-not-contain, r=alexcrichton
cargotest: Fix `with_*_does_not_contain` to support `[..]` and macro matching.
I changed it so that it is essentially the opposite of `with_*_contains` to keep it symmetric.
Any in-flight PRs using the old style will need to be updated (else they will incorrectly silently pass). Alternatively, we could rename the method to avoid that.
The following tests contained brackets, so they were not checking what they thought they were checking. I did a cursory look at them, but perhaps someone else could double-check that they make sense. Asserting what *doesn't* happen can be tricky since there is an infinite number of things that won't happen. Preferably a test would assert that it appears in one scenario and not another (like `incremental_profile` does), but some of them don't or can't.
BTW, would you be interested in a PR that adds some documentation to `cargotest`?
I've discovered things I didn't know where there. I think some docstrings on some of the methods, and a short guide for new contributors would be helpful.
Note that, due to the first commit, this still gives us all the benefits of #5249: if RUSTFLAGS is empty, we will run only a single rustc process, even if we can't cache it across different cargo invocations.
Auto merge of #5386 - ysimonson:new-metadata, r=matklad
Added new metadata fields
Addresses #5373.
`cargo metadata` should now include all of the non-optional suggested fields in the [API guidelines](https://rust-lang-nursery.github.io/api-guidelines/documentation.html#cargotoml-includes-all-common-metadata-c-metadata).
Auto merge of #5360 - euclio:metadata, r=alexcrichton
include package metadata in `cargo metadata`
Fixes #4819.
All-in-all a pretty small change. I'm a little concerned about threading the `toml::Value` all the way through however, should I make another type? Also, cloning the metadata value initially is maybe not ideal, since it's technically accessible through the original manifest. I figured this way was cleaner.
Auto merge of #5353 - matklad:features, r=alexcrichton
New semantics for `--features` flag
Historically, feature-related flags like `--all-features`,
`--no-default-features` and `--features` operated on the *current*
package. That is, `cargo --package foo --feature feat` would activate
`feat` for the package at the current working directory, and not for the
`foo` package. `-Z package-features` flag implements the more obvious
semantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:
* `--feature` flag affects the selected package. It is an error to
specify `--feature` with more than a single `-p`, or with `-p` outside
workspace (the latter could work in theory, but would be hard to
implement).
* `--all-features` and `--no-default-features` affect all selected
packages, and not the one at cwd.
* The package in `cwd` is not implicitly enabled when doing feature
selection. That is, `cargo build -Z package-features -p foo` could
select *less* features for various packages than `cargo build -p foo`.
Historically, feature-related flags like `--all-features`,
`--no-default-features` and `--features` operated on the *current*
package. That is, `cargo --package foo --feature feat` would activate
`feat` for the package at the current working directory, and not for the
`foo` package. `-Z package-features` flag implements the more obvious
semantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:
* `--feature` flag affects the selected package. It is an error to
specify `--feature` with more than a single `-p`, or with `-p` outside
workspace (the latter could work in theory, but would be hard to
implement).
* `--all-features` and `--no-default-features` affect all selected
packages, and not the one at cwd.
* The package in `cwd` is not implicitly enabled when doing feature
selection. That is, `cargo build -Z package-features -p foo` could
select *less* features for various packages than `cargo build -p foo`.
projects / cargo.git / log